The invention relates generally to formatting an object linking and embedding file so that the file can provide progressive viewing during file transfer operations.
Object embedding and linking (OLE, pronounced oh-lay) technology allows a user to "embed" or "link" different types of objects (e.g., text and graphic objects) into a common document. An embedded/linked object retains the data format of the application used to create it. In addition, the common document incorporates information about the format such as what application should be executed to view the embedded object.
The basic OLE concept has been extended through the definition of a structured storage model that treats a single file system entity as a structured collection of two types of objects; streams and storages. A stream object is the conceptual equivalent of a single disk file. Streams are the basic file system component in which data persists and are treated as a flat sequence of bytes (each stream has access rights and a single seek pointer). A storage object is the conceptual equivalent of a directory. Each structured storage file, referred to as a compound file, may contain any number of substorages and any number of streams.
One embodiment of the OLE structured storage model, targeted specifically for image data, is the FLASHPIX format. (See "The FlashPix Format Specification," version 1.0.1, July 1997.) FLASHPIX is a multi-resolution image format in which an image is stored as a series (hierarchy) of independent arrays, each array representing the image at a different spatial resolution. The hierarchy is created by starting with the highest resolution image, generally determined by the resolution of the image's capture device. Each successive image's resolution is reduced (decimated) by a factor of two in both the height and width until the final resolution fits within a 64-by-64 pixel area. As with all compound files, FLASHPIX files contain storages and streams. Allocation of space within a file for each of these elements is done in units called "sectors." The size of a sector may be specified at file creation time and is often 512 bytes. OLE compound files are organized into a series of logical components, each component being one or more sectors in length. After briefly describing some of these components, an example will be provided that shows how they are interrelated.
Referring to FIG. 1, logical components can include header 100, directory 102, file allocation table (FAT) 104, data 106, and metadata 108. Header 100 contains information vital to the identification and use of the OLE compound file including, for example, data specifying the size of a sector, and references to the first sector of directory 102 and FAT 104. There is one header in any compound file, and it is always begins at a file offset of zero. Directory 102 includes a reference to the first data sector for each stream in the OLE compound file. For example, if the OLE compound file is a FLASHPIX file having four images (one high resolution image and three lower resolution images), directory 102 will have a reference to the first data sector for each of the four images. FAT 104 is the primary space allocation table in an OLE compound file. Every sector in an OLE compound file is represented within FAT 104 in some fashion, including those sectors that are unallocated (free). Each entry in FAT 104 contains a reference to the next sector in an object's (e.g., an image's) chain of data sectors. Those FAT entries associated with the last data sector of an object contain a special end-of-chain value. (Directory 102 is represented as a standard chain of sectors within a FAT, but is separated here for logical clarity.) Data 106 includes one or more sectors associated with each user stream such as a FLASHPIX image. Within a stream, the information stored in data 106 is a sequence of arbitrary bytes; no restrictions are imposed on its content. Metadata 108 represents one or more sectors of user (e.g., application) defined information. Examples of metadata include the time and date a file was created and file author information.
Referring now to FIG. 2, consider a FLASHPIX file having two images--a high resolution image and a low resolution image. As required by the FLASHPIX specification, Header 100 includes information identifying the file as a FLASHPIX file 200 and a reference to the compound file's directory 202. Directory 102 includes references to the first sector associated with the compound file's metadata 204, low resolution (LOWRES) image data 206, and high resolution (HIRES) image data 208. High resolution image data reference 208 indicates the first data sector 210 in data component 106 associated with the high resolution image. The corresponding FAT entry 212 contains a reference to the image's next data sector 214, and so on until the last data sector 222 of the high resolution image is linked. The FAT entry 224 corresponding to the last data sector 222 contains a special end-of-chain value (EOC). A similar chain of data sectors and FAT entries exist for the low resolution images (a two data sector--226 and 228--stream) and the metadata (a one data sector--230--stream). In accordance with the FLASHPIX specification, all file components (e.g., FAT 104 and data 106) except header 100 may be located at any position in the file; header 100 must begin at file offset zero.
As long as a FLASHPIX file is resident on a local computer, the display of any one of the file's available resolutions can be fast. If the FLASHPIX file of FIG. 2 were to be transferred from a first computer system (e.g., a website) to a second computer system (e.g., an individual user's computer) using a standard browser executing the hypertext transport protocol (HTTP), however, it would not be possible for the user to view any of the file's images until the entire file was transferred. If the high resolution image is large, say more than one megabyte, the time required to complete a transfer can make use of FLASHPIX files unacceptable for many users. (The time to transfer an image is exacerbated by the fact that FLASHPIX files are 33% larger than the original, high resolution, image due to the lower resolution images included therein.) This "download time" constraint has become more and more significant with the increased use of computer networks (e.g., the internet and intranets) to access information.
The internet imaging protocol (IIP) was developed to provide access to FLASHPIX file images over computer networks. For example, one benefit of the IIP is that it can provide a progressive view of a file during the download process. Thus, the user does not have to wait until the entire FLASHPIX file is downloaded before they begin to see an image. This capability is similar, from the user's point of view, to the familiar progressive joint photographic experts group (JPEG) download mechanism. To obtain this benefit, however, a user must have access to a server-side executable (i.e., an IIP server application) capable of parsing and selectively transmitting any one of the images within a FLASHPIX file. Because IIP servers are not available to the typical user, who generally connects to the internet via local telephone lines, there is a need for a mechanism to allow progressive viewing of OLE structured files that does not require server side processing.